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(57) Abstract 

Vi** 1 ". (,0) for remotc P 8 *"'"* 01 updating of operating code located in a mobile unit (22. 24. 26. 28 or 30) is provided. The 
system ( 10) includes a manager host ( 16) and a mobile unit (22. 24. 26. 28 or 30). The manager host < 16) is operable to initial transmission 
mrough a communication network (12) of at least one discrete patch message defining at least one patch. The mobile unit (22 24 26 
28 or 30) is operable to receive the at least one patch message. The mobile unit (22. 24. 26. 28 or 30) is also operable to create patched 
operating code by merging the patch with current operating code located in the mobile unit (22. 24. 26. 28 or 30) and to switch execution to 
the patched operating code. The mobile unit (22. 24. 26. 28 or 30) can also receive at least one download message defining new operating 
code to replace the current operating code. * 
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REMOTE PATCHING OF OPERATING CODE IN AMOBILE UNIT 



TECHNICAL FIELD OF THE INVEWTTnfl 

This invention relates in general to the field of 
electronic systems, and more particularly to a system and 
method for remote patching of operating code located in a 
mobile unit. 
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BACKGROUND OF THE INVENTION 

Software suppliers and other sellers of computer 
systems often have a need for correcting or upgrading 
existing software used by their customers. Common 
methods of doing so include the distribution of floppy 
disks and tapes and the provision of modem support. 
However, the distribution of floppy disks and tapes is 
time consuming and forces the customer to use the old 
software while waiting for updates. Modem support can be 
used to link directly to the consumer's remote computer 
system and manually upgrade the software. However, such 
manual upgrade is time consuming, expensive and prone to 
human error. 

Additionally, a central computer system has been 
used to provide access to software updates from systems 
at fixed remote locations. One such system is disclosed 
in U.S. Patent No. 5,155,847 entitled Method and 
Apparatus for Updating Software at Remote Locations.*' 

U.S. Patent No. 5,155,847 discloses a central 
computer system that can monitor and record changes to 
versions of software. A user having a fixed remote 
system operating an old version of software may access 
the central computer system. If changes are applicable 
to the software used by the remote system, the central 
computer system can provide patches to the remote system 
for updating the software. 

However, the system disclosed by U.S. Patent No. 
5,155,847 discloses remote systems at fixed locations 
that access a central computer system over an on-line 
communication link that allows interactive and 
bidirectional communication. The remote systems 
participate in a single, continuous communication session 
that is terminated after the remote user receives the 
appropriate patches. 
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SUMMARY OF THE TNVFNTTQfJ 

In accordance with the present invention, 
disadvantages and problems associated with prior systems 
and methods for updating software have been substantially 
5 reduced or eliminated. One aspect of the present 

invention provides remote patching of operating code 
located in a mobile unit. 

According to an embodiment of the present invention, 
a system for remote patching of operating code located in 
10 a mobile unit is provided. The system includes a manager 

host and a mobile unit. The manager host is operable to 
initiate transmission through a communication network of 
at least one discrete patch message defining at least one 
patch. The mobile unit is operable to receive the at 
15 least one patch message. The mobile unit is also 

operable to create patched operating code by merging the 
at least one patch with current operating code located in 
the mobile unit and to switch execution to the patched 
operating code. 
20 According to another embodiment of the present 

invention, a method for remote patching of operating code 
located in a mobile unit is provided. At least one 
discrete patch message defining at least one patch is 
transmitted through a communication network. The at 
25 least one patch message is received in a first mobile 

unit where the first mobile unit is executing current 
operating code located in the mobile unit. Patched 
operating code is created in the mobile unit by merging 
the at least one patch with the current operating code. 
30 Execution in the mobile unit is switched to the patched 
operating code. 

A technical advantage of the present invention is 
allowing remote patching of operating code located in a 
mobile unit without physically touching the mobile unit 
35 or establishing a bidirectional and interactive 

communication link. The patching zi code r.ay be zo fix 
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software bugs, add new functionality, or completely 
replace the existing version of code with a new version. 

An additional technical advantage of the present 
invention is the provision of mobile units operable to 
5 interpret patch messages and create patched operating 

code therefrom without affecting the normal functions 
performed by the mobile unit. 

According to another technical advantage of the 
present invention, patches are broadcast to a number of 
10 mobile units from a central location. The central 

location operates to keep track of the location of each 
mobile unit and how to deliver patch messages. The 
central location can also tailor the broadcasts of 
patches to different mobile units. 
15 According to an additional technical advantage of 

the present invention, patches are sent as several 
discrete patch messages to a mobile unit, reception of 
the discrete patch messages is verified by the mobile 
unit, and patch information is combined by the mobile 
unit to create a complete patch file used to patch 
current operating code. The patches can be sent in a 
single or multiple communication sessions. 



20 
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BRIEF DESCRIPTION OP THE DRAWINGS 

For a more complete understanding of the present 
invention and for further features and advantages, 
reference is now made to the following description taken 
5 in conjunction with the accompanying drawings, wherein 

like reference numerals represent like parts, in which: 

FIGURE 1 illustrates one embodiment of a system for 
remote patching of operating code located in a mobile 
unit ; 

10 FIGURE 2 is a schematic representation of one 

embodiment of a manager host; 

FIGURE 3 is a schematic representation of one 
embodiment of a mobile unit; 

FIGURE 4 illustrates one embodiment of message 
15 formats for patch messages used to represent a patch 

file; 

FIGURE 5 is a flow chart showing one embodiment of a 
method of operation of a mobile unit for remote patching 
of operating code located in the mobile unit; 
20 FIGURE 6 is a flow chart showing one embodiment of a 

method of creating patched operating code in a mobile 
unit; and 

FIGURE 7 is a flow chart showing one embodiment of a 
method of resetting and restarting with patched operating 
25 code. 
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DETAILED DESCRIPTION OF THE INVENT TON 

FIGURE 1 illustrates one embodiment of a system, 
indicated generally at 10, for remote patching of 
operating code located in a mobile unit. System 10 
comprises a communication network 12 that includes an 
enhanced services complex 14 . 

Communication network 12 may include one or a 
combination of several communication technologies, such 
as a wireless communication network like the cellular 
telephone network, a land-line communication network, 
another portion of the public switched telephone network 
(PSTN) , a dedicated communication link, or any other 
appropriate communication link. Communication network 12 
can support data transmissions or data and voice 
transmissions simultaneously. The type of communication 
link utilized in communication network 12 may vary 
between components of system 10, as described below. 

A manager host 16 is coupled to enhanced services 
complex 14 using communication network 12. A first client 
host 18 and a second client host 20 also are coupled to 
enhanced services complex 14 in a similar manner as 
manager host 16. Manager host 16, first client host 18, 
and second client host 20 can be separate from or 
integral to enhanced services complex 14 . 

A first mobile unit 22 and a second mobile unit 24 
are associated with first client host 18 and are coupled 
to enhanced services complex 14 using communication 
network 12. Similarly, a third mobile unit 26, a fourth 
mobile unit 28 and a fifth mobile unit 30 are associated 
with second client host 20 and are coupled to 
communication network 12. In the preferred embodiment, 
the communication link of the communication network 12 
that couples mobile units 22, 24, 26, 28, and 30 with the 
enhanced services complex 14 is a wireless or mobile 
communication network, such as a cellular telephone 
network . 
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In the embodiment of FIGURE 1, manager host 16 
provides support to client host 18 and client host 20 
with respect to processing of information messages 
exchanged between enhanced services complex 14 and 
associated mobile units 22 , 24, 26, 28 and 30 via 
communication network 12. For example, client host 18 
and client host 20 can receive status information from 
and provide dispatching information to mobile units 22 
and 24 and mobile units 26, 28 and 30, respectively. 
Manager host 16 provides support for systems operating in 
both client hosts 18 and 20 and mobile units 22, 24, 26, 
28 and 30 . 

At times, manager host 16 might desire to enhance, 
correct, or replace current operating code located in one 
or more of the mobile units. A patch file can be created 
that defines one or more patches that need to be made to 
provide enhancements or corrections to the current 
operating code. In addition to the patch or patches, the 
patch file can provide a new version number and a new 
checksum for the resulting patched operating code. The 
version number can provide information such as the phase, 
release, revision and modifications made. Furthermore, 
as described below, the messages can also define a- 
completely new version of the software that is to replace 
the current version running at the mobile units. 
Therefore, the description of the components and 
operation of sending patch messages to mobile units 
applies equally to the transmission of download messages 
that combine to form new operating code to replace the 
current operating code. 

According to the teachings of the present invention, 
the patch file can be represented by a set of discrete 
patch messages. Each patch message can be sized as a 
discrete data payload suitable for transmission in a 
message through communication network II. Manager host 
16 can transmit the discrete pater, rressaaes to 
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appropriate mobile units. When a mobile unit receives 
the patch messages, the mobile unit can verify the patch 
messages, merge the defined patches with the current 
operating code, and switch execution to the patched 
operating code. In order to receive a complete patch 
file, each mobile unit receives all of the patch messages 
in the set representing the patch file. The transmission 
of discrete patch messages does not require a dedicated 
or interactive communication link, and can be performed 
in several communication sessions. For example, due to 
the inherent limitations of wireless communication, the 
communication link to the mobile unit may be lost. 
System 10 can then reestablish the communication link and 
continue transmission of the current patch message. 

In this manner, operating code located in a mobile 
unit may be maintained and updated without the need for 
manager host 16 physically to contact the mobile unit. 
In addition, manager host 16 can provide varying levels 
of enhancements to mobile units associated with different 
client hosts and remotely maintain the operating code 
associated with each level of enhancement. This can be 
accomplished by addressing patch messages to the 
appropriate mobile units. For example, mobile units 22 
and 24 associated with client host 18 can have a 
different version of operating code than mobile units 26, 
28 and 30 associated with client host 20. 

Manager host 16 can transmit discrete patch 
messages, according to the teachings of the present 
invention, in order to overcome limitations inherent in 
communication network 12. The communication link to the 
mobile units in communication network 12 can comprise any 
wireless or mobile communication system using land-based 
or space-based transmitters, receivers, or transceivers, 
such as a cellular telephone network, a personal 
communication system (PCS) , a specialized mobile radio 
(SMR) , an enhanced specialized mobile radio (ESMR) , 
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citizen's band (CB) , a paging network, a satellite-based 
communication network, or any other communication system 
supporting transmission of data to the mobile units. 
Due to the nature of wireless communication, 
5 transmission of large amounts of data over communication 

network 12 can be expensive, error prone, and risky. For 
example, wireless communications may not be appropriate 
for an on-line session that requires bidirectional and 
interactive communications over an extended period of 

10 time. Further, in such a system, a mobile unit might be 

required to limit normal operation until the transmission 
of data was complete. Normal communication of messages 
between a client host and an associated mobile unit would 
be disrupted and the mobility of the mobile unit would be 

15 restricted. For example, if an on-line communication 

link over a cellular network were used, a mobile unit 
would be forced to stop at the edge of network coverage 
in order to maintain the communication link. The present 
invention overcomes these limitations of wireless 

20 communication by broadcasting short messages over one or 
several separate communication sessions that do not 
require interactive or substantial bidirectional 
communication. Furthermore, the present invention can 
resume transmissions when the communication link is lost 

25 without sacrificing a significant loss of previously 
transmitted data. 

Each mobile unit 22, 24, 26, 28, and 30 can be 
associated with a vehicle, person, or other mobile 
entity. Each mobile unit 22, 24, 26, 28, and 30 operates 

30 by executing the current operating code located in the 

mobile unit. The mobile units 22, 24, 26, 28, and 30 may 
perform various communicating, locating, and fleet 
management functions as described in U.S. Patent No. 
5,155,689 entitled "Vehicle Locating and Communicating 

35 Method and Apparatus'. 
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In operation, manager host 16 can accomplish remote 
patching of operating code located in mobile units 20, 
22, 24, 26, 28 and 30 by transmitting a set of discrete 
patch messages through communication network 12. The 
5 discrete patch messages collectively represent a patch 

file defining at least one patch to be made to current 
operating code located in one or more of mobile units 20, 
22 , 24, 26, 28 and 30, Each mobile unit 20, 22, 24, 26 , 
28 and 30 is operable to receive the patch messages 

10 transmitted by manager host 16. Each mobile unit 20, 22, 

24, 26, 28 and 30 can create patched operating code by 
merging the defined patch or patches with the current 
operating code and can switch execution to the patched 
operating code. The discrete patch messages can comprise 

15 packets that can be transmitted before or after voice 

communication, during dead time of conversation or other 
suitable time period for transmitting packet sized data. 

Manager host 16 can address patch messages to mobile 

20 units as appropriate for the patch file being 

transmitted. Manager host 16 can address a patch message 
to one of the mobile units, to all of the mobile units, 
or to a group of mobile units. A patch message addressed 
to all of the mobile units can be referred to as a 

25 broadcast message. A patch message addressed to a group 

can correspond to mobile units associated with client 
host 18 or client host 20. For example, manager host 16 
can address a patch message such that it will be 
transmitted to both mobile unit 22 and mobile unit 24 

30 associated with client host 18. 

In the embodiment of FIGURE 1, enhanced services 
complex 14 of communication network 12 operates to handle 
all messages transmitted between manager host 16, client 
host 18, client host 20 and mobile units 22, 24, 26, 28, 

35 and 30. In particular, enhanced services complex 14 

maintains information to establish comrr.ur.icat ion with 
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mobile units 22, 24, 26, 28, and 30 using communication 
network 12 . Enhanced services complex 14 then ensures 
that message data is delivered with integrity. Part of 
the operation of enhanced services complex 14 is to 
handle patch messages transmitted by manager host 16 to 
mobile units 22, 24, 26, 28, and 30. Enhanced services 
complex 14 recognizes whether a patch message is 
addressed to one mobile unit, a group of mobile units or 
all mobile units, establishes communication with the 
appropriate mobile units, and transmits the discrete 
patch message. Application Serial No. 08/095,166 
entitled "Method and Apparatus for a Nation-wide Cellular 
Telephone Network" describes in detail the components and 
functionality of enhanced services complex 14, and is 
herein incorporated by reference. Enhanced services 
complex 14 and manager host 16 can be separate components ■ 
in system 10, or integrated into a single platform as 
described in Application Serial No. 08/095,166. 

A technical advantage of the present invention is 
allowing remote patching of operating code located in a 
mobile unit without physically touching the mobile unit 
or establishing an on-line communication link. An 
additional technical advantage of the present invention 
is the provision of mobile units operable to interpret 
patch messages and create patched operating code 
therefrom without affecting the normal functions 
performed by the mobile unit. According to another 
technical advantage of the present invention, a mobile 
unit can provide feedback regarding the current version 
of operating code located in the mobile unit and can 
provide verification of completion of patches to the 
current operating code. 

FIGURE 2 is a schematic representation of one 
embodiment of a manage* host 16 . Manager host 16 
communicates with mobile units using link 40 to 
communication network 12. Link 40 may be one or a 
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combination of dedicated or switched telephone lines in 
the mobile or land- line public switched telephone network 
(PSTN) , or other land-based communication links, 
satellite-based communication links, or any other 
5 suitable communication link that allows manager host 16 

to transmit messages to or receive messages from 
communication network 12. 

A message received from a mobile unit enters manager 
host 16 through a modem, DTMF coder /decoder , or other 

10 data encoder 42 and passes to central controller 44. 

Conversely, a message transmitted to a mobile unit passes 
from central controller 44 through coder /decoder 4 2 to 
communication network 12. 

Memory 4 6 and input /output device 4 8 are coupled to 

15 central controller 44. Central controller 44 receives 

and processes messages from mobile units. Central 
controller 44 also transmits messages to mobile units 
including patch messages addressed to appropriate mobile 
units. Memory 46 may be RAM, ROM, CD-ROM, removable 

20 memory devices, or any other device that allows storage 

and retrieval of data. Input/output device 48 includes 
any variety of output devices, such as a display, a 
speaker to provide audible information, removable storage 
media, or any other appropriate output device. 

25 Input /output device 48 may also include a variety of 

input devices, such as a keyboard, mouse, touchscreen, 
removable storage media, or any other appropriate input 
device . 

FIGURE 3 is a schematic representation of one 
30 embodiment of a mobile unit, indicated generally at 50. 

Mobile units 22, 24, 26, 28, and 30 of FIGURE 1 may be 
constructed in a similar manner as mobile unit 50 of 
FIGURE 3. Mobile unit 50 comprises a mobile 
communications device 52 including an antenna 54 coupled . . 
35 to a transceiver 56. A handset 58 is also coupled to 

transceiver 56. Transceiver 56 is coupled co bus drivers 
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6 0 which in turn are coupled to a modem, DTMF 
coder/decoder, or other data encoder 62. Coder/decoder 
62 is coupled to processor 64. Transceiver 56 is also 
coupled to processor 64 over link 65. 

Processor 64 is coupled to a first flash. bank 66 and 
to a second flash bank 68 and to a RAM 70. First flash 
bank 66, second flash bank 68, and RAM 70 may be RAM, 
ROM, CD-ROM, removable memory devices, or any other 
device that allows storage and retrieval of data. 
Furthermore, first flash bank 66, second flash bank 68, 
and RAM 70 may be separate devices or portions of one or 
more devices. An input device 72 and an output device 74 
are also coupled to processor 64 . 

In operation, mobile communications device 52 
receives and transmits messages over communication 
network 12, The messages received by transceiver 56 are 
passed to processor 64 either over link 65 or over other 
appropriate path such as bus drivers 60 and coder/decoder 
62. Processor 64 manages the operation of mobile unit 
50. Handset 58 provides additional voice or data 
communication. First flash bank 66 and second flash bank 
68 are operable to store operating code for execution by 
processor 64, and RAM 70 is operable to provide processor 
64 with memory work space. 

In operation, processor 64 executes current 
operating code out of first flash bank 66 or second flash 
bank 68. Processor 64 performs functions according to 
the current operating code. When processor 64 receives 
one. or more patch messages representing a complete patch 
file, processor 64 analyzes the patch messages to 
determine whether processor 64 should initiate a patch 
process. If processor 64 is currently executing an 
appropriate version of operating code suitable to receive 
the defined patch or patches, processor 64 initiates the 
patch process to implement the patch or patches defined 
by the patch messages . 
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Processor 64 stores patch information defined by the 
patch messages in RAM 70. If processor 64 is executing 
out of first flash bank 66, processor 64 creates patched 
operating code in second flash bank 68 by merging the 
patch information with the current operating code. After 
the patched operating code is created, processor 64 sets 
a flag indicating that further execution should occur out 
of second flash bank 68. Processor 64 then initiates a 
reset so that mobile unit 50 restarts with processor 64 
executing the patched operating code located in second 
flash bank 68. An analogous switch from second flash 
bank 68 to first flash bank 66 can occur when the current 
operating code is located in second flash bank 68. In 
this manner, mobile unit 50 can enhance, correct, or 
replace the current operating code based upon discrete 
patch or download messages transmitted over communication 
network 12. 

The components of mobile unit 50 shown in FIGURE 3 
may be packaged into one or more housings. Mobile unit 
50 may be mounted to a vehicle or associated with other 
movable objects. Mobile unit 50 may also..be packaged as 
a portable, hand-held device that provides personal 
functions. For example, a portable, hand-held mobile 
unit 50 may be used by surveyors, rescue teams, 
25 individuals that may change forms of transportation, or 
any other application requiring portability of mobile 
unit 50. 

FIGURE 4 illustrates one embodiment of message 
formats for transmission over communication network 12 to 

30 mobile units. The first three message types relate to 
patch messages for incorporating patches of code into 
existing code on the mobile units. The last three 
messages relate to direct program download messages for 
replacing the current code in the mobile unit with a new 

35 version of code. All message formats shown in FIGURE 4 

are inserted in a general message format, that begins 
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with a start, message type, length, and identifier field 
and ends with a checksum and end field. These messages 
can be sized to accommodate optimal or preferred message 
sizes for different technologies in communication network 
5 12 . 

The patch messages include: a new patch file 
message, an append patch message, an append data message, 
and a delete unincorporated patches message. These patch 
messages are designated as type "0", "1" , "2", and "3" 
10 respectively. In the illustrated embodiment, each patch 
message includes up to 252 bytes of information. 

A new patch file message operates to indicate to a 
mobile unit that a set of one or more patch messages 
representing a new patch file is being transmitted. As 
15 described above, the set of patch messages will define a 
patch or patches to be made to current operating code. 
The new patch file message also operates to define the 
first patch. 

A new patch file message includes eight fields, as 

20 shown in FIGURE 4. The new patch file message includes a 

"message type" field which is one byte and holds a "0" 
indicating that the message is a new patch file message. 
A "patch file ID" field is one byte and comprises a 
unique identification number for the patch file 

25 represented by the set of patch messages. Each patch 
message associated with the patch file includes this 
unique patch file ID. A "software version" field is 
eight bytes and provides an indication of which operating 
code versions are appropriate for receiving the patch or 

30 patches contained in the represented patch file. The 

software version can operate as a mask to indicate such 
things as phase, release, revision, and modifications 
made. A "number of patches" field is one byte and gives 
the total number of patches that are included in the set 

35 of patch messages identified by the patch file ID. Each 
patch may be represented by one or more discrete patch 
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messages. A "memory address to be modified by patch" 
field is four bytes and identifies the memory address of 
the current operating code to be modified by the first 
patch which is defined by the new patch file message. A 
5 "starting address in patch memory space" field is four 

bytes and defines the starting address in the patched 
operating code where the first patch is to be written. A 
"number of bytes of data" field is one byte and defines 
the number of bytes of information in a "patch data" 

10 field. Lastly, the "patch data" field can include from 

one to 23 2 bytes and holds the data associated with the 
first patch. 

An append patch message operates to define an 
additional patch to be made to current operating code. 

15 The append patch message includes six fields that are 

similar to fields in the new patch file message. A 
"message type field" is one byte and is a "1" to indicate 
an append patch message. A "patch file ID" field is one 
byte and comprises the unique identification number for 

20 the patch file. This patch file ID must match the patch 

file ID contained in the previous new patch file message. 
A "memory address to be modified by patch" field is four 
bytes and identifies the memory address of the current 
operating code to be modified by the additional patch 

25 defined by the append patch message. A "starting address 
in patch memory space" field is four bytes and defines 
the starting address in the patched operating code where 
the additional patch is to be written. A "number of 
bytes of data" field is one byte and defines the number 

30 of bytes of information in a "patch data" field. Lastly, 

the "patch data" field can include from one to 241 bytes 
and holds the data associated with the additional patch. 

An append data message operates to provide patch 
extension data where the data associated with a patch 

35 requires more space than is available in the patch data 

field of a new patch file message or an append patch 
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message. The append data message includes three fields. 
A "message type" field is one byte and is a "2" to 
indicate an append data message. A "patch file ID" field 
is one byte and comprises the unique identification 
5 number for the patch file. This patch file ID must match 

the patch file ID contained in the previous new patch 
file message. Lastly, a "patch extension data" field can 
include from one to 250 bytes and holds additional data 
associated with a patch. There can be one or more append 

10 data messages associated with a new patch file message or 

an append patch message depending upon the number of 
bytes of data needed to define the associated patch. 

The delete unincorporated patches message includes a 
single "message type" field which is one byte and holds a 

15 "3". After receiving an entire set of patch messages, 

the mobile unit may perform an end-to-end checksum of the 
patched messages or the patched operating code. If there 
is a checksum error, the mobile unit informs manager host 
16 of the checksum error. Manager host 16 may then send 

20 the delete unincorporated patches message to the mobile 

unit so that the transmission of patch messages can be 
repeated. 

A new patch file message defines one patch, and each 
append patch message defines an additional patch. Thus, 

25 for a set of discrete patch messages, the total of the 
new patch file message plus the append patch messages 
equals the "number of patches" field in the new patch file 
message. The set of discrete patch messages also can 
include a number of append data messages. Append data 

30 messages provide extension data as necessary for a new 
patch file message or one of the append patch messages. 
Append data messages complete the patch definition if any 
of the patches require more bytes of data than available 
in the "patch data" field of a new patch file message or 

35 an append patch message. 
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Using the patch message formats illustrated in 
FIGURE 4, a complete patch file may be transmitted 
through communication network 12 using at least one 
discrete patch message representing the patch file. Each 
5 discrete patch message can have a separate checksum 

associated with it. Thus, each message can be separately 
verified. A mobile unit can initiate a patch process 
after all patch messages in a set are received and 
verified. For the embodiment of patch messages 

10 illustrated in FIGURE 4, the patch messages are received 

in proper sequence although the length of time between 
receipt of each patch message is unimportant. Other 
embodiments of discrete patch messages can include 
additional fields that define such things as sequence and 

15 could be received in any order. Each mobile unit can 

operate to determine whether a patch message has been 
missed and to request a patch message or complete set to 
be retransmitted. 

A patch file and associated patch messages can be 

20 generated manually or automatically. In general, a patch 

may insert a jump command into the current operating code 
causing a jump to additional code. The additional code 
can return execution to the point following the jump 
command. A patch may alternatively simply overwrite 

25 current operating code. Additionally, the current 

operating code may include empty space following each 
module to provide room for expansion by patches. Other 
embodiments of patches are possible. The embodiments of 
patch messages and patches described with respect to 

3 0 FIGURE 4 are not intended nor should be construed to 

limit the scope of the present invention. 

The direct program download messages include: a 
prepare for download, a download message, and a program 
checksum message. These patch messages are designated as 

35 type M", "5 tt and "6", respectively. In the illustrated 
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embodiment , each download message includes up to 109 
bytes of information. 

The prepare for download message includes a single 
"message type" field which is one byte and holds a "4", 
which informs the mobile unit that a new program download 
is about to be transmitted. In response, the mobile unit 
erases first flash bank 66 or second flash bank 68 in 
preparation for receiving new operating code. 

The download message transmits the actual data that 
combines to form the new operating code that replaces the 
current operating code of the mobile unit. Normally, the 
mobile unit receives several download messages that 
combine to form the new operating code. The download 
message includes six fields, as shown in FIGURE 4. The 
download message has a "message type" field which is one 
byte and holds a "5" indicating that the message is a 
download message. The "record type" field contains two 
bytes and indicates the format of the remaining data in 
the message. The "record length" field is one byte long 
and indicates the length of the remaining message. The 
"starting address" field can be between two and four 
bytes long and defines a starting address in first flash 
bank 66 or second flash bank 68 to insert the data 
contained in the download message. The "program data" 
field contains up to 100 bytes that define a portion of 
the new operating code for the mobile unit. The "record 
checksum" field contains a single byte that is used by 
the mobile unit to confirm the integrity of the received 
download message. 

The new program checksum message includes two 
fields. A one -byte "message type" field holds a "6", 
which informs the mobile unit that the program download 
is complete and that a program checksum value follows. A 
"new checksum" field contains a two-byte checksum to 
verify the integrity of trie new operating code combined 
from the download messages received at the mobile unit. 



i 
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Using the download message formats illustrated in 
FIGURE 4, new operating code may be transmitted through 
communication network 12 using at least one download 
message representing the new operating code. Each 
5 download message includes a separate record checksum to 

verify the integrity of each download message 
transmission. Upon receipt and verification of a single 
download message, the mobile unit transmits an 
acknowledgement to manager host 16 that the download 

10 message has been accurately received. The program data 

from each download message is then loaded into first 
flash bank 66 or second flash bank 6 8 at the address 
specified in the download message. Additionally, an end- 
to-end checksum on the new operating code can be used to 

15 verify the complete set of download messages loaded in 

memory. After verifying receipt of the new operating 
code, the mobile unit swaps out the current operating 
code with the new operating code and initiates a reset to 
execute the new code. The download messages can be 

20 received in any sequence and over any number of 

communication sessions. By receiving acknowledgements 
from the mobile unit, manager host 16 or enhanced 
services complex 14 can monitor which download messages 
have been sent and when the transmission of the set of 

25 download messages is complete. 

FIGURE 5 is a flow chart showing one embodiment of a 
method of operation of a mobile unit for remote patching 
operating code. The method of FIGURE 5 is one embodiment 
of a patch process by which a mobile unit can receive a 

30 set of patch messages collectively representing a patch 

file, can merge the defined patches with the current 
operating code to create patched operating code, and can 
switch execution to the patched operating code. A 
similar operation could be used to receive several 

35 download messages defining new operating code to replace 
the current operating code in the mobile unit. 
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In step 100, the mobile unit receives an initial 
patch message which includes a software version. In one 
embodiment of the present invention, the initial patch 
message comprises a new patch file message as described 
5 with respect to FIGURE 4. In step 102, the mobile unit 

compares the software version provided by the initial 
patch message with the software version of the mobile 
unit's current operating code. In step 104, the mobile 
unit determines whether the software version of the 

10 current operating code is appropriate for the patches 

defined by the set of patch messages. If not, the mobile 
unit transmits an appropriate error message in step 106. 
This error message can be addressed to manager host 16, 
an associated client host 18 and 20, or both. 

15 If the current operating code is an appropriate 

version, the mobile unit checks whether the initial patch 
message is valid in step 108. This validity check can 
comprise a checksum technique or other appropriate 
validity check. If the patch message is not valid, the 

20 mobile unit transmits an appropriate error message in 

step 106. If the patch message is valid, then the mobile 
unit stores the associated patch information in step 110. 
The mobile unit may also send an acknowledgment that the 
patch message was valid. In one embodiment, the patch 

25 information is stored in RAM 70 that is used as a work 
space. In step 112, the mobile unit determines whether 
there are additional patch messages to be received. If 
so, the mobile unit receives the next patch message in 
step 114. In one embodiment of the present invention, 

30 the next patch message comprises either an append patch 

message or an append data message as described with 
respect to FIGURE 4. The mobile unit checks the validity 
of the next patch message in step 108, and, if valid, 
stores the patch information in step 110. If the next 

35 patch message is not valid, the mobile unit sends an 
appropriate error message in step 106. 



BNSOOCtD: <WO 9632670A1 I > 



W ° 96/32679 PCT/US96/04505 

22 



The mobile unit continues in this manner until all 
patch messages are received for the patch file. The 
mobile unit uses the "number of patches" defined by the 
new patch message to determine the total number of patch 
5 messages associated with a patch file. In one embodiment 

of the present invention, there is a new patch file 
message plus a number of append patch messages, the total 
equal to the "number of patches" field in the new patch 
file message format shown in FIGURE 4. The number of 

10 append data messages can be determined from respective 

"number of bytes of data" fields in the new patch file 
message or the append patch messages. 

As described above, each patch message is a discrete 
message. When the mobile unit identifies an incoming 

15 message as a patch message, the mobile unit handles the 
patch message accordingly. The patch messages can be 
transmitted over a long or short period of time, and in 
one or many separate communication sessions. The mobile 
unit waits until a complete set of patch messages has 

20 been received and then continues to step 116 of FIGURE 5. 

Alternatively, the mobile unit may begin to create the 
patched operating code while still receiving additional 
patch messages from manager host 16 . 

In step 116, the mobile unit creates patched 

25 operating code. To do so, the mobile unit merges the 

patch or patches defined by the set of patch messages 
into the current operating code to create a patched 
operating code. One embodiment of this process is 
described with respect to FIGURE 6. This process is not 

30 necessary if the mobile unit receives a set of download 

messages that in themselves define the new operating code 
to be executed. 

After creating the patched operating code, the 
mobile unit verifies the patched operating code in step 

35 118. This step can be performed using a checksum or 

other appropriate technique. In step 120. the mobile 
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unit determines whether the result of verification 
indicates valid patched operating code. If not, the 
mobile unit transmits an appropriate error message in 
step 106. The mobile unit may then receive a delete 
5 unincorporated patch messages from manager host 16, and 

the process can be repeated at step 100. 

If the patched operating code is valid, the mobile 
unit resets and restarts such that execution is switched 
to the patched operating code in step 122. One 

10 embodiment of this reset and restart process is described 

with respect to FIGURE 7. After patching is completed, 
the mobile unit executes and operates according to the 
patched operating code. If a new set of patch messages 
is received, the mobile unit repeats the patching process 

15 to create and switch to new patched operating code. In 

this manner, the current operating code in the mobile 
unit may be remotely patched to provide enhancements or 
corrections as part of ongoing support of the mobile 
unit. Similarly, a set of download messages can provide 

20 an entirely new version of software to replace the 
current version. 

FIGURE 6 is a flow chart showing one embodiment of a 
method of creating patched operating code. -In this 
embodiment, the mobile unit comprises first flash bank 66 

25 and second flash bank 68 and can execute operating code 
located in either flash memory bank. The mobile unit 
also comprises RAM 70 holding the patch information 
supplied by the set of patch messages. 

In. step 130, the mobile unit prepares the second 

30 flash bank 68 to receive patched code. Second flash bank 

68 is the one in which the current operating code is not 
located. In step 132, the mobile unit begins the process 
of merging patches into the current operating code. In 
step 132, the mobile unit determines whether the next 

35 memory address of the current operating code in the first 
flash bank is to be modified by a pacch beginning with 
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the first memory address that holds part of the current 
operating code. If so, in step 134, the mobile unit 
merges the patch with the current operating code and 
stores the resulting patched operating code in the second 
5 flash bank 68. In one embodiment of the present 

invention, the mobile unit steps through byte-by-byte, 
and upon detecting a patch, inserts bytes of a patch. 
After inserting bytes of a patch, the mobile unit 
continues with the next byte in the current operating 

10 code. If the next memory address in the first flash bank 

66 is not to be modified, the mobile unit copies the 
associated byte of operating code into the second flash 
bank 68 in step 136- 

In step 138, the mobile unit determines whether 

15 patching is complete. If not, the mobile unit continues 

at step 132. This process proceeds byte -by-byte, 
sequentially, until a current operating code memory 
address matches a patch message "memory address to be 
modified" field. The mobile unit continues merging 

20 patches with the current operating code until the current 

operating code has been processed completely from 
beginning to end and all patches have been inserted. In 
this manner, patched operating code is created in the 
second flash bank 68 by merging the current operating 

25 code in first flash bank 66 with the patches defined by 

the set of patch messages. The second flash bank 68 then 
contains complete patched operating code that is ready 
for verification and execution by the mobile unit. 

FIGURE 7 is a flow chart showing one embodiment of a 

30 method of resetting and restarting with patched or new 

operating code stored in second flash bank 68. This 
process operates to switch execution to either patched 
operating code generated from a set of patch messages or 
new operating code generated from a set of download. 

35 messages. The embodiment described with reference to 

FIGURE 1 comprises switching execution from first flash 
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bank 66 which holds the current operating code to second 
flash bank 68 which holds the patched or new operating 
code. An analogous method could be used to switch from 
second flash bank 68 to first flash bank 66. 
5 In step 150, the mobile unit copies into RAM 70 the 

code needed to switch execution to second flash bank 68. 
In this embodiment of the present invention, this code 
comprises a copy of boot code executed by the mobile unit 
when a reset occurs. The boot code includes instructions 

10 to cause execution of the patched or new operating code 

stored in second flash bank 68. In step 152, the mobile 
unit executes a system reset from RAM to restart and 
switch execution to second flash bank 68. In this 
embodiment, the mobile unit accomplishes the switch by 

15 setting a flag in RAM indicating that the mobile unit 

should execute operating code located in second flash 
bank 68. After the reset occurs, the mobile unit begins 
power-up with the patched or new operating code. 
Alternatively, the mobile unit may physically swap the 

20 contents of first memory bank 66 and second memory bank 

68, perform a reset, and execute the new or patched 
operating code now residing in first memory bank 66. 

In step 154, the mobile unit determines whether the 
power-up checksum is valid. If the power-up checksum is 

25 valid, then the patched or new operating code located in 
the second flash bank 68 is valid, and the mobile unit 
continues execution of the patched or new operating code. 
If the power-up checksum is not valid, then in step 156, 
the mobile unit executes another system reset from RAM to 

30 restart and switch execution back to first flash bank 66. 

Thus, if the patched or new operating code is not valid, 
the mobile unit returns to executing the current 
operating code as it existed prior to receiving a set of 
patch messages or download messages. 

35 In an alternative embodiment, the mobile unit copies 

the contents of second flash bank €8 to first flash bank 
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66 after verifying the receipt and compilation of patched 
or new operating code. Mobile unit then executes the 
patched or new operating code residing in first flash 
bank 66. If the operating code in first flash bank 66 
5 becomes corrupted, then mobile unit can switch execution 

to the copy of the same operating code stored in second 
flash bank 68. 

The system and method of remote patching or updating 
of operating code located in a mobile unit of the present 

10 invention provides numerous technical advantages. A 

manager host can provide support for operating code 
located in one or more mobile units. The manager host 
can transmit a set of discrete patch messages 
collectively representing a patch file defining one or 

15 more patches to be made to operating code currently 

executed by one or more mobile units. The patches can 
comprise enhancements or corrections to the current 
operating code. The mobile units are capable of 
receiving the patch messages, creating patched operating 

20 code, and switching execution to the patched operating 

code without interrupting normal functions. The manager 
host can also transmit a set of discrete download 
messages collectively representing new operating code to 
replace the current operating code being executed by the 

25 mobile unit. 

Although the present invention has been described 
with respect to several embodiments, it should be 
understood that various changes, substitutions and 
alterations can be made thereto without departing from 

30 the spirit and scope of the invention as defined by the 

appended claims. 
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WHAT 15 CLA IMED 15: 

1. A system for remote patching of operating code 
located in a mobile unit, comprising: 
5 a manager host operable to initiate transmission 

through a wireless communication network of at least one 
discrete patch message defining at least one patch; and 

a first mobile unit operable to receive the at least 
one discrete patch message, the first mobile unit further 
10 operable to create patched operating code by merging the 

at least one patch with current operating code located in 
the first mobile unit and to switch execution to the 
patched operating code. 

15 2. The system of Claim 1, wherein the current 

operating code and the patched operating code comprise 
object code for a processor located in the first mobile 
unit . 

20 3. The system of Claim 1, wherein the at least one 

discrete patch message collectively represent a patch 
file that defines the at least one patch . 

4. The system of Claim 1, wherein the at least one 
25 discrete patch message comprises one discrete patch 

message . 

5. The system of Claim 4, wherein the one discrete 
patch message defines one patch to be made to the current 

30 operating code. 

6. The system of Claim l f wherein the at least one 
discrete patch message comprises a plurality of discrete 
patch messages . 

35 
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7. The system of Claim 6, wherein the at least one 
discrete patch message defines a plurality of patches to 
be made to the current operating code. 

5 8. The system of Claim 7, wherein the at least one 

discrete patch message includes at least one new patch 
file message and at least one append patch message. 

9. The system of Claim 8, wherein the at least one 
10 discrete patch message further includes at least one 

append data message. 

10. The system of Claim 1, wherein the mobile unit 
separately verifies the at least one discrete patch 

15 message. 

11. The system of Claim 1, wherein the mobile unit 
separately verifies the at least one discrete patch 
message, and the mobile unit verifies the patched 

20 operating code. 

12. The system of Claim 1, further comprising: 

a second mobile unit operable to receive the at lest 
one patch message, the second mobile unit further 

25 operable to create patched operating code by merging the 
at least one patch with current operating code located in 
the second mobile unit and to switch execution to the 
patched operating code; and 

wherein the manager host is further operable to 

3 0 address the at least one discrete patch message such that 

the at least one discrete patch message is transmitted to 
the first mobile unit but not to the second mobile unit. 
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13. The system of Claim 12, wherein the first 
mobile unit is associated with a first client host, and 
the second mobile unit is associated with a second client 
host , 

5 

14. The system of Claim 12, wherein the manager 
host is further operable to address the at least one 
discrete patch message such that the at least one 
discrete patch message is transmitted to the first mobile 

10 unit and to the second mobile unit. 



15. The system of Claim 14, wherein the first 
mobile unit is associated with a first client host, and 
the second mobile unit is associated with a second client 
15 host. 



16. The system of Claim 1, wherein the wireless 
communication network includes an enhanced services 
complex operable to establish communication with the 
20 first mobile unit and to transmit the at least one patch 
message to the first mobile unit. 
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17. A mobile unit, comprising: 

a memory operable to store current operating code; 
a receiver operable to receive the at least one 
discrete patch message transmitted through a wireless 
communication network, the at least one discrete patch 
message defining at least one patch to be made to the 
current operating code; and 

a processor coupled to the memory and to the 
receiver, the processor operable to execute the current 
operating code, to process the at least one discrete 
patch message, to create patched operating code by 
merging the at least one patch with the current operating 
code, and to switch execution to the patched operating 
code. 

18. The system of Claim 17, wherein the current 
operating code and the patched operating code comprise 
object code for the processor. 

19. The system of Claim 17, further comprising: 
a second memory coupled to the processor; and 
wherein the processor is further operable to store 

patch information provided by the at least one discrete 
patch message in the second memory. 

20. The system of Claim 19, further comprising: 
a third memory coupled to the processor; and 
wherein the processor is further operable to store 

the patched operating code in the third memory after the 
0 patched operating code is created. 

21. The system of Claim 20, wherein the processor 
is further operable to switch execution between the first 
memory and the. third memory. 
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22. The system of Claim 21, wherein the processor 
is further operable to switch execution between the first 
memory and the third memory after a system reset. 

5 23. The system of Claim 20, wherein the first 

memory comprises a first flash bank, the second memory 
comprises a random- access memory, and the third memory 
comprises a second flash bank. 
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24. A set of discrete patch messages for defining a 
plurality of patches to be made to current operating code 
located in a mobile unit, comprising: 

a new patch file message operable to define a first 
5 patch to be made to current operating code; 

an append patch message operable to define an 
additional patch to be made to the current operating 
code ; and 

an append data message operable to extend patch 
10 definition information. 



25. The set of patch messages of Claim 24, wherein 
the new patch file message comprises information 
including a patch file ID, a software version, a number 

15 of patches, and first patch data. 

26. The set of patch messages of Claim 25, wherein 
the append patch message comprises information including 
a patch file ID, and additional patch data. 

20 

27. The set of patch messages of Claim 26, wherein 
the append data message comprises information including a 
patch file ID, and patch extension data. 
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28. A method of operation of a mobile unit for 
remote patching of operating code, comprising: 

receiving at least one discrete patch message 
defining at least one patch to be made to current 
5 operating code located in the mobile unit; 

creating patched operating code by merging the at 
least one patch with the current operating code to create 
the patched operating code; and 

switching execution to the patched operating code. 

10 

29. The method of Claim 28, wherein the step of 
creating comprises creating patched operating code 
comprising object code for a processor located in the 
mobile unit. 

15 

30. The method of Claim 28, further comprising the 
step of verifying each patch message after the step of 
receiving, 

20 31. The method of Claim 28, further comprising the 

step of verifying the patched operating code after the 
step of creating. 

32. The method of Claim 28, wherein the step of 
25 creating patched operating code comprises the steps of: 
processing the current operating code byte-by-byte 
to determine whether a patch is to be made to each byte 
of the current operating code; and 

storing the patched operating code in a memory byte- 
30 by-byte as the current operating code is processed. 
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33. The method of Claim 28, wherein the step of 
switching comprises the steps of: 

copying boot code into a first memory; 

executing a system reset from the first memory such 
that execution is switched from a second memory to a 
third memory; and 

restarting using patched operating code in the third 
memory . 

34. The method of Claim 33, further comprising the 
step of validating patched operating code executed from 
the third memory. 
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35. A method for remote patching of operating code 
located in a mobile unit, comprising: 

transmitting at least one discrete patch message 
defining at least one patch through a communication 
5 network; 

receiving the at least one patch message in a first 
mobile unit, the first mobile unit executing current 
operating code located in the first mobile unit; 

creating patched operating code in the first mobile 
10 unit by merging the at least one patch with the current 

operating code; and 

switching execution in the first mobile unit to the 
patched operating code. 

15 36. The method of Claim 35, wherein the step of 

creating comprises creating patched operating code 
comprising object code for a processor located in the 
first mobile unit. 

20 37, The method of Claim 35, wherein the step of 

receiving comprises separately verifying the at least one 
discrete patch message. 

38. The method of Claim 37, wherein the step of 

25 switching comprises verifying the patched operating code. 

39. The method of Claim 35, wherein the step of 
transmitting is accomplished using an enhanced services 
complex in a communication network. 

30 

40. The method of Claim 35, wherein the step of 
transmitting further comprises addressing the at least 
one discrete patch message such that the at least one 
discrete patch message is transmitted to the first mobile 

35 unit but not to a second mobile unit. 
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41. The method of Claim 40, wherein the first 
mobile unit is associated with a first client host, and 
the second mobile unit is associated with a second client 
host . 

42. The method of Claim 40, wherein the first 
mobile unit and the second mobile unit are associated 
with a first client host. 
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